home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 5920 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.8 KB
  1. Path: rcp6.elan.af.mil!rscernix!danpop
  2. From: danpop@mail.cern.ch (Dan Pop)
  3. Newsgroups: comp.os.msdos.programmer,comp.lang.c
  4. Subject: Re: open vs fopen?
  5. Date: 20 Feb 96 15:13:40 GMT
  6. Organization: CERN European Lab for Particle Physics
  7. Message-ID: <danpop.824829220@rscernix>
  8. References: <uEYFxc9nX8WX083yn@mbnet.mb.ca> <4f8bev$6tr@hermes.louisville.edu> <2d3avbl60.alamito@marketgraph.xs4all.nl> <4ftusv$181@newshost.cyberramp.net> <danpop.824430285@rscernix> <4g39d4$ej8@newshost.cyberramp.net> <danpop.824525964@rscernix> <4gbdfr$l2a@newshost.cyberramp.net>
  9. NNTP-Posting-Host: ues5.cern.ch
  10. X-Newsreader: NN version 6.5.0 #7 (NOV)
  11.  
  12. In <4gbdfr$l2a@newshost.cyberramp.net> sinan@cyberramp.net (John Noland) writes:
  13.  
  14. >The original question was something to the effect of, "What is the difference 
  15. >between fopen and open and when should I use one over the other?". Are you 
  16. >saying I should have answered with, "They are functionally identical. There 
  17. >is no difference between them, whatsoever. Always use fopen(), PERIOD!!!".
  18.  
  19. For comp.lang.c, read/write and fread/fwrite _are_ functionally identical
  20. and "Always use fopen(), PERIOD!!!" is the right message that has to be
  21. sent to c.l.c readers.  Those who're really interested in the differences
  22. should be sent to a platform specific newsgroup, because the differences
  23. _are_ platform specific.
  24.  
  25. >>The stdio buffering is a red herring, because it can be always disabled, if it 
  26. >>isn't needed.
  27. >
  28. >That's true. But if you're going to disable it, why not use the other routines? 
  29. >They're smaller. I guess portablity would be a valid reason. The stdio routines 
  30. >are ANSI and the others aren't. 
  31.  
  32. The stdio routines provide more functionality: what's the raw I/O 
  33. equivalent of fscanf?  A very good reason to prefer stdio even if you
  34. decide (for whatever reason) to disable the stdio buffering.
  35.  
  36. >>In my <stdio.h> file, the constant BUFSIZ is 512. 
  37. >
  38. >>Aha, I see where the magical value 512 came from.  The systems I'm working
  39. >>on have BUFSIZ set to values between 1024 (mostly BSD-based Unices) and 
  40. >>32768 (OpenVMS).  So, your claim that <stdio.h> sets the size of the
  41. >>buffer to 512 bytes is bogus.  BTW, even 512 is a humongous size for a
  42. >>single density 8" floppy disk, which needs to read four sectors to fill
  43. >>such a buffer.
  44. >
  45. >This has an extemely condescending feel to it. Aha? Magical value? 
  46. >Your claim that <stdio.h> sets the size of the buffer? The clouds
  47. >have parted. I see clearly now. Dan has bestowed upon me the titles
  48. >C NEWBIE and UNIX Illiterate. 
  49. >BUFSIZ is in <stdio.h>. To say that the size of the buffer is set **IN**
  50. >the stdio.h file is not wrong or misleading. 
  51.  
  52. Right.  But to say that the value of BUFSIZ is set to 512 in <stdio.h>
  53. is both wrong and misleading.  Saying: "on my system/platform/compiler
  54. BUFSIZ is set to 512 in <stdio.h>" would have been perfectly OK, although
  55. fairly irrelevant, since neither comp.os.msdos.programmer nor 
  56. comp.lang.c are dedicated to your particular compiler.
  57.  
  58. >Not by any stretch of the
  59. >imagination. But you managed anyway. Since this thread is running in
  60. >both the c.l.c and msdos.programmer groups, I used the value most DOS 
  61. >compilers use. 
  62.  
  63. And leading other people to believe that it is universal is OK, isn't it?
  64. Especially in the context of c.l.c, where the value used by most DOS
  65. compilers is utterly irrelevant.
  66.  
  67. >Again,sorry Dan. It just seemed like you were bragging about UNIX and 
  68. >putting down DOS (god forbid).
  69.  
  70. Could you post the paragraphs (from this particular thread) which gave
  71. you this impression?
  72.  
  73. >DOS is inferior to UNIX in almost every respect. Why isn't UNIX the
  74. >most dominant OS in the world? 
  75.  
  76. Are you sure this question belongs to these newsgroups?  Keep your cheap
  77. sarcasms for yourself, please.
  78.  
  79. Dan
  80. --
  81. Dan Pop
  82. CERN, CN Division
  83. Email: danpop@mail.cern.ch 
  84. Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
  85.